Decide servers should have accounted for this already #6
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This cuts the document by about half.
In the original version of this document, I assumed that attacker control over the key_share list was a novel scenario that servers were not expected to previously account for. After all, we went through quite a lot of trouble to capture both ClientHellos in the handshake transcript.
On reflection after MT filed issue #5, I think that was too timid of a position. Although rfc8446bis improves the wording, RFC 8446 already was quite clear that the key_share list may be an arbitrary subset of the supported_groups list and doesn't reflect the full preferences. So we can reasonably claim that any key_share-first server either:
has considered this and believes the groups are comparable in preference, or
did not understand the protocol and failed to implement their desired policy correctly.
The first is a perfectly valid choice. It's not a good choice between ECDH and post-quantum, but it's perfectly defensible between post-quantum options or between two ECDH curves. The second is a server bug and the server's responsibility to fix, even if it is exacerbated by new client behavior.
If we believe that, there is nothing wrong with a client predicting
key_share
based on any heuristic, be it DNS, random probes to avoid compat risks of large ClientHellos, whatever you negotiated previously, the phase of the moon, racing two connections, or a popularity contest. So now all the stuff around prediction-safe vs prediction-unsafe groups is cut, and we just include a discussion in Security Considerations that this was okay.